The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @nick-a8c.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: nick-a8c.

Co-authored-by: jameskoster <[email protected]>
Co-authored-by: t-hamano <[email protected]>
Co-authored-by: tyxla <[email protected]>
Co-authored-by: mirka <[email protected]>
Co-authored-by: hanneslsm <[email protected]>
Co-authored-by: paaljoachim <[email protected]>
Co-authored-by: ciampo <[email protected]>
Co-authored-by: jasmussen <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: +24 B (0%)

Total Size: 1.77 MB

_{compressed-size-action}

Looking so much better!

The background blur is a nice touch.

I was wondering how it might look it the travel distance was even smaller - like 90% scale.

The travel distance should be from 90% scale to 100%. So I wonder will it make a subtle difference changing it from 80% to 90%.
https://share.cleanshot.com/y5KQgCMt

Flaky tests detected in 30773e4.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10614980603
📝 Reported issues:

• [Flaky Test] Redirection after template creation #60678 in /test/e2e/specs/site-editor/site-editor-url-navigation.spec.js

I tested this PR.

• I did not see any issues like those reported in #43877 in my environment.
• I also tried changing the throttling in Chrome browser, - but there was no lag in the animation itself.
• No lags in the Firefox browser

The situation may have changed since the lag issue was reported, but I would be grateful if you could test it to see if the lag still occurs.

Visually, I like the blur. UX-wise I don't. Sometimes it is handy to still see the names of the already created pages behind the modal.

Please o please do not blur the background as it is as @hanneslsm says can be useful on occasion to still be able to see the background while the modal is open.

A blurred background creates disconnection. If one steps away for moment while the modal is open and then returns to the page one might be wondering.... what was I doing here. The modal still needs to keep connection with the rest of the page.

So in general for modals please keep the connection with the background as it creates a safety/ a hint for the user seeing the connection of modal and the rest of the page.
Having elements associated with the full page helps the user get a perspective on what is going on by seeing multiple elements that are associated with each other. They might notice one element more than others and by association that will help the user understand what is going on.

I agree that it is useful for users who can see the screen to be able to see the content behind an open modal. However, a modal is essentially a dialog element and should be a document independent of its background.

Users who rely solely on screen readers and keyboard navigation cannot access the content outside the modal. In other words, I think the modal itself needs to convey sufficient intent. On the other hand, blurring the background has the added benefit of allowing users to focus on the content inside the modal.

If it is difficult to understand the intent of the modal without the background content, it might be that the modal itself is not providing a sufficient content, and the modal content might need to be reconsidered.

However, I am not an accessibility expert, so I would like to hear other people's opinions.

However, a modal is essentially a dialog element and should be a document independent of its background.
[...]
Users who rely solely on screen readers and keyboard navigation cannot access the content outside the modal.
[...]
If it is difficult to understand the intent of the modal without the background content, it might be that the modal itself is not providing a sufficient content, and the modal content might need to be reconsidered.

I agree with @t-hamano — technically, the Modal component implements dialog semantics , which implies that the user can only interact with dialog's contents, and the rest of the page should become inert.

Having said that, I understand if folks still prefer to avoid blurring the background.

Appreciate sweating the details. In this case, although the animation curve feels slightly nicer (at a glance), removing the directionality by replacing the translate with a scale doesn't seem like a win. I always think of animation as orchestration according to a physical system: where's this item coming from? Where's it going? What's it made of? In the case of trunk, it may not be the most refined at the moment, but it's coming from outside the canvas, vertically below, "where modals live". This is acknowledging that on mobile, similar modals behave like a bottom card. If it simply comes from the center and scales up, it doesn't come from anywhere.

I completely agree with your point about the importance of orchestration, Joen, especially in mobile interfaces. On smaller screens, having the modal originate from the bottom can create a natural, grounded flow that feels connected to the user’s touch and the overall layout. It makes sense for elements to come from where the user’s interactions typically occur, providing a clear and intuitive experience.

However, in the context of a desktop interface, I believe that keeping the modal centered has its own distinct advantages. When the modal originates from the center, it instantly captures the user’s attention. The motion starting from where the modal will ultimately rest creates a direct connection between the beginning and end of the animation, making the transition feel more cohesive and less distracting. This seamless movement helps maintain the user's focus on the modal’s content rather than on the motion itself, ensuring that the interaction remains straightforward and unobtrusive.

Animations that start from the center and scale up or fade in provide a sense of stability, particularly on desktop screens where the user's eye is naturally drawn to the center. This approach minimizes the amount of eye movement required to track the animation, reducing potential distraction or disorientation that could occur if the modal originated from the bottom and moved upwards. On larger screens, this can be especially important as it allows for a more comfortable and intuitive viewing experience.

In terms of storytelling and visual narrative, a modal that grows or fades into place from the center feels like it’s an organic part of the interface. This approach aligns with key motion design principles that emphasize continuity and coherence, suggesting that the modal is an inherent part of the current context rather than an external element entering from an arbitrary location. This integration helps maintain a consistent visual narrative and enhances the overall user experience.

I'll explore different modal animations in various context, including both centered and vertical appearances. This should help us compare and find the best solution.

These are just my two cents. No matter which option we choose, our main goal should be to help users navigate smoothly and clearly.

I don't mind removing the blur and discussing that separately. But I would suggest; if users need to see content behind a modal, then it is most probably the incorrect UX.

Good discussion about the point of origin!

a modal that grows or fades into place from the center feels like it’s an organic part of the interface [...] suggesting that the modal is an inherent part of the current context rather than an external element entering from an arbitrary location.

This resonates with me. While I understand this is a subjective view, my feeling is the modal conceptually emerges directly from the clicked element, rather than existing off-screen, waiting to be triggered. More specifically, it's the contents of the modal that originate from the element – the modal container itself is merely a vessel, and its off-screen position before activation feels largely inconsequential.

Given the lack of a practical way to visually represent this idea, and considering that some modals might appear on-load, having them originate from the center of the screen on desktop, with a scale/fade animation seems like a solid alternative to me.

I made some adjustments to the animation as suggested by @nick-a8c, and updated the gif in the OP.

What do you think @jasmussen?

Let's merge this one and gather any wider feedback.

Before we move on, can we look at having a subtle exit animation as well?

I think @ciampo has been looking into some options there. Related: #64777

Before we move on, can we look at having a subtle exit animation as well?

Trying it out in #65203

@nick-a8c would you mind sharing your WordPress.org username so we can ensure you're properly credited in the 6.7 release next week?

@jeffpaul
Of course!
My WordPress.org username is: nebojsajurcic